At present, most mobile communication networks are circuit switched (CS) networks. Operators have built mature and rich service platforms based on CS networks. Among the service platforms, the mobile switching center (MSC) is responsible for call routing and service logic execution, for example, call transfer. With the continuous development of mobile technologies, a service network based on IP switching, namely, an IP multimedia subsystem (IMS), is emerging. Compared with the CS network, the IMS network provides higher bandwidth and supports more services. The core units of the IMS network are a serving-call session control function (S-CSCF) and various application servers (ASs). The S-CSCF is responsible for routing call requests to a proper AS when conditions are met. The AS is responsible for executing the service logic. The telephony application server (TAS), a kind of AS, controls the implementation of all supplementary services in the IMS network.
Being complex, the IMS network cannot be deployed within a short period of time. The CS network and IMS network will inevitably coexist within a certain period. To save construction costs, operators need to unify the service platforms of the CS network and IMS network and transfer the functions of the CS network to the IMS network. As a result, the IMS centralized services (ICS) emerge. In the ICS process, a user equipment (UE) sets up an IMS call through voice media over the CS network, the AS in the IMS network provides the call service. The CS bearer is implemented by setting up a CS call between the UE and a newly introduced IMS call control function (ICCF). In addition, the service processing logic in the MSC is weakened or removed. In this technology, the media gateway control function (MGCF) is required to convert the signaling and media between the CS network and the IMS network.
The voice call continuity (VCC) technology ensures the continuity of the voice calls transferred between the CS network and the IMS network. The core of this technology is a VCC AS. All calls or sessions must pass through the VCC AS in the IMS network. The VCC AS can act as a back-to-back user agent (B2BUA) for subsequent inter-domain transfer control.
The call transfer service is a supplementary service. A user who is set with the call transfer service may transfer a received call to a preset third party user. The call transfer services are classified into call deflection service and call forwarding service. In the prior art, the call transfer service between the CS network and the IMS network is implemented according to the method shown in FIG. 1. As shown in FIG. 1, a UE 2 in the IMS network originates a call to a VCC-enabled UE 1 in the CS network, and the UE 1 triggers the call transfer service to transfer to the call to the UE 3. The S-CSCF, VCC AS, and TAS shown in FIG. 1 reside in the home network of the UE 1. FIG. 1 shows the process of transferring a call according to the prior art. The process includes the following steps.
Step 101: The UE 2 sends a call request to the UE 1.
In this step, the UE 2 sends a call request to the UE 1 through the TAS, S-CSCF, call transfer server, MGCF, and MSC of the UE 1.
Step 102: The UE 1 triggers the call transfer service.
In this step, the call transfer service triggered by the UE 1 can be the call deflection (CD) service (for example, the UE 1 enters the number of the UE 3), call forwarding service (for example, the call is forwarded when the UE 1 is busy), or any other call transfer mode.
Step 103: After obtaining the information that the UE 1 triggers the call transfer service, the MSC of the UE 1 obtains the call transfer information set by the UE 1 and sends a request for redirecting to the IMS network to the call transfer server. The service request can contain the third party information, namely, the number of the UE 3.
Step 104: After receiving the redirection request, the call transfer server allocates an IP multimedia routing number (IMRN) to the call and sends the IMRN to the MSC of the UE 1.
The IMRN number is used to route the calls from the CS network to the call transfer server in the IMS network.
Step 105: The MSC of the UE 1 uses the IMRN as the called number and sends a call request to the MGCF by using the IAM command.
Step 106: The MGCF converts the CS signaling into a Session Initiation Protocol (SIP) Invite message and sends the call request to the S-CSCF through the Invite message. The Invite message carries the called number, namely, IMRN.
Step 107: The S-CSCF routes the call request to the call transfer server according to the initial filter criteria (iFC).
Step 108: After receiving the Invite message, the call transfer server sends a call request to the S-CSCF by generating a new Invite message according to the number of the UE 3 obtained in step 103.
Step 109: The S-CSCF routes the received call request to the TAS according to the iFC.
Step 110: The TAS, acting as a B2BUA, sends a call request to the S-CSCF by generating a new Invite message.
Step 111: The S-CSCF routes the received call request to the UE 3.
Step 112: The UE 3 returns an ACK message (200 OK) to the UE 2. The ACK message is returned according to the call request signaling; that is, the responses to all call requests are returned according to the signaling paths of the call requests.
As shown in FIG. 1, after step 103 is performed, the call transfer server allocates an IMRN to the call request from the MSC of the called UE, and the call request still needs to be routed to the call transfer server according to the IMRN. The call transfer server sends a call request to the S-CSCF according to the obtained number of the UE 3, and the S-CSCF routes the call request to the TAS, and then the TAS acting as the B2BUA sends the call request to the UE 3 through the S-CSCF. That is, in the call process after the UE 1 triggers the call transfer service, the call request still needs to be routed to the call transfer server, thus inevitably causing redundant call request signaling and a waste of network resources.